The Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for message-oriented middleware. The defining features of AMQP are message orientation, queuing, routing (including point-to-point and publish-and-subscribe), reliability, and security.
AMQP mandates the behavior of the messaging provider and client to the extent that implementations from different vendors are interoperable, in the same way as SMTP, HTTP, FTP, etc. have created interoperable systems. Unlike JMS, which defines an API and a set of behaviors that a messaging implementation must provide, AMQP is a wire-level protocol. A wire-level protocol is a description of the format of the data that is sent across the network as a stream of bytes.
Consequently, any tool that can create and interpret messages that conform to this data format can interoperate with any other compliant tool irrespective of implementation language.
AMQP is a binary, application layer protocol, designed to support a wide variety of messaging applications and communication patterns efficiently. It provides flow controlled, message-oriented communication with message-delivery guarantees such as at-most-once (where each message is delivered once or never), at-least-once (where each message is certain to be delivered, but may do so multiple times), and exactly-once (where the message will always certainly arrive and do so only once), and authentication and/or encryption based on SASL and/or TLS. It assumes an underlying reliable transport layer protocol such as Transmission Control Protocol (TCP).
RabbitMQ is open source message broker software (sometimes called message-oriented middleware) that implements AMQP. RabbitMQ is used for messaging, for example, in Flexera Flexnet® Advanced Lifecycle Management (ALM). It is used to queue and process/replicate data to Flexnet Operations (LLM) and other components in the system, such as Usage Analytics Service (UAS) and License Fulfillment Service (LFS). In use, RabbitMQ includes a publisher and consumer. In one implementation of ALM, data from all tenants flows through two queues. FIG. 1 is a block schematic diagram showing a messaging environment, such as a RabbitMQ environment. In FIG. 1, a notification is sent from a multi-tenant app 10 via a message dispatcher 11. In this implementation, each queue 12a, 12b has its own consumer 13a, 13b, which routes the messages as processed data 14, 15.
This approach is problematic because there is so much data at times that the single consumer cannot keep up during peak periods. Furthermore, all data is processed serially, so other tenants are negatively impacted if one tenant generated lots of data/messages that had to be processed first. Thus, one tenant with heavy traffic could flood the queue and cause delays in processing messages from other tenants
This bottleneck is particularly a problem for data replicated to Cloud components because sending each message over the Internet takes a significant amount of time. Thus, in another implementation each tenant's data flows through a different queue and has its own consumer (1 tenant=1 consumer=1 thread), as shown in FIG. 2, which is a block schematic diagram showing a messaging environment where each tenant's data flows through a different queue 20 and has its own consumer 21. This implementation provides one queue per tenant.
If the same architecture shown in FIG. 2 is applied to another part of the system, the system could spin up so many consumer threads that it could adversely affect the system, e.g. where # of threads=# of tenants*2, and that number would continue to grow as more tenants were added.
FIG. 3 is a block schematic diagram showing a messaging environment where each tenant's data flows through a different queue 20, 30 for replication. The provision of one consumer 21, 31 per thread results in an inordinate number of threads.